home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 10 / AACD 10.iso / AACD / Programming / mpatrol / README < prev   
Encoding:
Text File  |  2000-05-16  |  3.5 KB  |  68 lines
  1. README FOR THE MPATROL LIBRARY
  2.  
  3.  
  4. This file contains an overview of the mpatrol library.  The documentation for
  5. the library currently exists as a manual in TeXinfo format located in the doc
  6. directory or as a set of UNIX manual pages located in the man directory.  A
  7. quick reference card is also available.  For instructions on how to build and
  8. install the mpatrol library see the manual.
  9.  
  10.  
  11. Introduction
  12.  
  13.     The mpatrol library is yet another link library that attempts to diagnose
  14.     run-time errors that are caused by the wrong use of dynamically allocated
  15.     memory.  If you don't know what the malloc() function or operator new[] do
  16.     then this library is probably not for you.  You have to have a certain
  17.     amount of programming expertise and a knowledge of how to run a command
  18.     line compiler and linker before you should attempt to use this.
  19.  
  20.     Along with providing a comprehensive and configurable log of all dynamic
  21.     memory operations that occurred during the lifetime of a program, the
  22.     mpatrol library performs extensive checking to detect any misuse of
  23.     dynamically allocated memory.  All of this functionality can be integrated
  24.     into existing code through the inclusion of a single header file at
  25.     compile-time.  On UNIX and Windows platforms (and AmigaOS when using gcc)
  26.     this may not even be necessary as the mpatrol library can be linked with
  27.     existing object files at link-time or, on some platforms, even dynamically
  28.     linked with existing programs at run-time.
  29.  
  30.     All logging and tracing output from the mpatrol library is sent to a
  31.     separate log file in order to keep its diagnostics separate from any that
  32.     the program being tested might generate.  A wide variety of library settings
  33.     can also be changed at run-time via an environment variable, thus removing
  34.     the need to recompile or relink in order to change the library's behaviour.
  35.  
  36.  
  37. Further information
  38.  
  39.     Due to their very nature, problems with dynamic memory allocations are
  40.     notoriously difficult to reproduce and debug, and this is likely to be the
  41.     case if you find a bug in the mpatrol library as it might be extremely hard
  42.     to reproduce on another system.  Details on how to report bugs are given in
  43.     the manual, but it would be very useful if you could try to provide as much
  44.     information as possible when reporting a problem, and that includes having a
  45.     look in the library source code to see if it's obvious what is wrong.
  46.     However, please try to read the FAQ first in case your question or problem
  47.     is covered there since it is usually updated every time I receive a question
  48.     about mpatrol.
  49.  
  50.     The latest version of the mpatrol library can always be found at
  51.     `http://www.cbmamiga.demon.co.uk/mpatrol/', and any correspondence relating
  52.     to mpatrol (bug reports, enhancement requests, compliments ;-) should be
  53.     sent to <mpatrol@cbmamiga.demon.co.uk>.  I normally only check my e-mail
  54.     about once or twice a week, so don't expect an immediate response.  I can
  55.     also be reached at <graeme@epc.co.uk> but that is my work e-mail address.
  56.     There is now also a discussion group at `http://www.egroups.com/group/mpatrol/'
  57.     where you can post mpatrol-related questions but you must first subscribe to
  58.     the group before you can send mail to it.
  59.  
  60.     Oh, and always remember to do final release builds without the mpatrol
  61.     library as the library is much slower than normal malloc implementations and
  62.     uses much more memory.
  63.  
  64.     Happy debugging!
  65.  
  66.     Graeme Roy, 11th October, 1999.
  67.     Edinburgh, Scotland.
  68.